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Label Advertisement Discipline 
for LDP Forwarding Equivalence Classes (FECs) 


Abstract 


The label advertising behavior of an LDP speaker for a given 
Forwarding Equivalence Class (FEC) is governed by the FEC type and 
not necessarily by the LDP session’s negotiated label advertisement 
mode. This document updates RFC 5036 to make that fact clear. It 
also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the 
label advertisement mode for all currently defined LDP FEC types. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc7358. 
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Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The Label Distribution Protocol (LDP) [RFC5036] allows label 
advertisement mode negotiation at the time of session establishment. 
The LDP specification also dictates that only a single label 
advertisement mode be negotiated, agreed upon, and used for a given 
LDP session between two Label Switching Routers (LSRs). 


The negotiated label advertisement mode defined in RFC 5036 and 
carried in the LDP Initialization message is only indicative. It 
indicates how the LDP speakers on a session will advertise labels for 
some Forwarding Equivalence Classes (FECs), but it is not a rule that 
restricts the speakers to behave in a specific way. Furthermore, for 
some FEC types the advertising behavior of the LDP speaker is 
governed by the FEC type and not by the negotiated behavior. 


This document updates [RFC5036] to make that fact clear. It also 


updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to 
indicate, for each FEC type that has already been defined, whether 
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the label binding advertisements for the FEC are constrained by the 
negotiated label advertisement mode or not. Furthermore, this 
document specifies the label advertisement mode to be used for all 
currently defined FECs. 


2. Label Advertisement Discipline 


To remove any ambiguity and conflict regarding a label advertisement 
discipline among different FEC types sharing a common LDP session, 
this document specifies a label advertisement discipline for FEC 
types. 


This document introduces the following types for specifying a label 
advertisement discipline for a FEC type: 


- DU (Downstream Unsolicited) 
- DoD (Downstream on Demand) 
- As negotiated (DU or DoD) 

- Upstream ([RFC6389]) 

- Not applicable 

- Unknown 


2.1. Update to RFC 5036 


Section 3.5.3 of [RFC5036] is updated to add the following two 
statements under the description of "A, Label Advertisement 
Discipline": 


- Each document defining an LDP FEC must state the applicability of 
the negotiated label advertisement discipline for label binding 
advertisements for that FEC. If the negotiated label 
advertisement discipline does not apply to the FEC, the document 
must also explicitly state the discipline to be used for the FEC. 


- This document defines the label advertisement discipline for the 
following FEC types: 


4+---------- 4+---------- 4-------------------------------- + 
| FEC Type | FEC Name | Label Advertisement Discipline | 
4+---------- 4+---------- 4-------------------------------- + 
| 0x01 | Wildcard | Not applicable | 
| 0x02 | Prefix | As negotiated (DU or DoD) | 
4+---------- 4+---------- 4-------------------------------- + 
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2.2. Specification for LDP FECs 


The label advertisement discipline for currently defined LDP FEC 
types is listed in Section 4. 


This document updates the respective RFCs in which these FECs are 
introduced and defined. 


3. Security Considerations 


This document only clarifies the applicability of an LDP session’s 
label advertisement mode and hence does not add any LDP security 
mechanics and considerations to those already defined in the LDP 
specification [RFC5036]. 


4. IANA Considerations 


This document mandates the specification of a label advertisement 
discipline for each defined FEC type and hence IANA’s "Forwarding 
Equivalence Class (FEC) Type Name Space" registry under IANA’s "Label 
Distribution Protocol (LDP) Parameters" registry has been extended as 
follows: 


- Added a new column titled "Label Advertisement Discipline" with 
the following possible values: 


DU 

DoD 

As negotiated (DU or DoD) 
Upstream 

Not applicable 

Unknown 


- Made this document an additional reference for the registry itself 
and for all affected registrations. 


- Kept other columns of the registry in place and populated as they 
were. 
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Discipline for 


LDP FECs 


October 2014 


the updated registry looks 


like: 

+ + + + + + + 

|Value|Hex | Name | Label | Reference |Notes/ 

| | | |Advertisement | |Registration | 

| | | |Discipline | |Date | 

+ + + + + + + 

| o | 0x00 | Reserved | | | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 1 |Ox01|Wildcard |Not applicable| [RFC5036] | 

| | | | | [RFC7358] | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 2 |0x02|Prefix |As negotiated | [RFC5036] | 

| | | | (DU or DoD) | [RFC7358] | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 4 | 0x04 |CR-LSP | DoD | [RFC3212] | 

| | | | | [RFC7358] | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

5 |0x05|Typed Wildcard |Not applicable| [RFC5918] | | 

| | |FEC Element | | [RFC7358] | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 6  |0x06|P2MP | DU | [RFC6388] | 

| | | | | [RFC7358] | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 7  |0x07|MP2MP-up | DU | [RFC6388] | 

| | | | | [RFC7358] | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 8  |0x08|MP2MP-down | DU | [RFC6388] | 

| | | | | [RFC7358] | | 

+----- 4+----+--------------- +-------------- +----------- +------------ + 

| 9 |0x09|HSMP-upstream |DU | [RFC7140] | 2014-01-09 | 

| | | | | [RFC7358] | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 10 |0x0A|HSMP-downstream|DU, Upstream | [RFC7140] | 2014-01-09 | 

| | | | | [RFC7358] | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 128 |0x80|PWid | DU | [RFC4447] | 

| | |FEC Element | | [RFC7358] | | 

+----- +----+--------------- +-------------- +----------- +------------ + 

| 129 |0x81|Generalized | DU | [RFC4447] | 

| | |PWid | | [RFC7358] | | 

| | |FEC Element | | | | 

+----- +----+--------------- +-------------- +----------- 4+------------ + 

| 130 |0x82|P2MP PW |Upstream | [P2MP-PW] | 2009-06-03 | 

Upstream [RFC7358] 
FEC Element 

+----- +----+--------------- +-------------- +----------- +------------ + 
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posto a tas Se SSeS Poe Sse SSS ste eS Sto Pores Sse + 
| 131 |0x83|Protection | DU | [FAST-PROT]| 2010-02-26 | 
| | |FEC Element | | [RFC7358] | | 
+----- 4+----4--------------- +-------------- 4+----------- +------------ + 
| 132 |0x84|P2MP PW | DU | [P2MP-Pw] | 2014-04-04 | 
| | |Downstream | | [RFC7358] | | 
| | |FEC Element | | | | 
+----- +----+-------------- +-------------- +----------- +------------— + 
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